In an Infrastructure as a Service (IaaS) computing model, cloud service providers hypothecate and comingle physical storage, compute, and network devices and allow tenants to use logically partitioned sets (“pools”) of these resources to deploy virtual machines on cloud service provider-owned and managed hardware. A virtual machine is a software computer that runs an operating system much like a physical computer. The hardware is shared by multiple tenants. Tenants deploy and manage these virtual machines via web interface or API calls to a Cloud Infrastructure Manager Server (“fabric controller”, VMware vCloud Director, and the like). Tenants pay a subscription fee for these services and third party Operating Systems running in these virtual machines are sometimes licensed through the cloud service provider. In this model, tenants generally require exclusive control of their network pool and may define their internet protocol (IP) address space for these virtual machines in accordance with corporate policy or an internally defined schema in layer 3 of the Open Systems Interconnect (OSI) model.
Therefore the cloud service provider is unable to dictate or shape a tenant's IP address assignments of the tenant's virtual machines. This can be especially challenging when tenants require the ability to extend their existing external network infrastructure to these network pools (for example in a hybrid cloud computing model, or for data migration, or coexistence with on premise infrastructure in the tenant's pre-existing Kerberos realm (“domain”). As a result, IP address conflicts naturally emerge between tenants, and cloud service provider keep these network pools isolated at layer 2 of the OSI Model in order to avoid security risks—such as denial of service—due to IP address conflicts. As a result, cloud service providers are unable to deliver any services above Layer 3 over the network to the tenant without introducing cumbersome Network Address Translations for every tenant virtual machine. Examples of such services in layer 7 of the OSI model can include DaaS, e.g., cloud service provider brokered CITRIX XENAPP and MICROSOFT REMOTE DESKTOP SERVICES connections.
The cloud service provider has an internal network topology, which is usually different from a topology of the corporate or internal network of each tenant. The topologies of the cloud service provider and each tenant may be different because each of those entities may have a unique or customized scheme of allocating IP addresses over the respective network. When the number of tenants being serviced by the cloud service provider is high, the likelihood of an IP address conflict between tenants is also high. There is a high likelihood of IP addresses conflict because there is an increased chance of a tenant assigning a computer within its internal network a particular IP address that has been already used by another tenant in its computer network. Therefore, the cloud service provider cannot concurrently provide network services to both tenants without the added complexity and limitations of network address translation for each computer in each tenant's network.